home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000985_cja@castle.edinburgh.ac.uk _Wed Apr 28 10:03:42 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  6KB
  1. Return-Path: <cja@castle.edinburgh.ac.uk>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA01041; Wed, 28 Apr 93 10:03:42 MET DST
  4. Received: from sun2.nsfnet-relay.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA02708; Wed, 28 Apr 1993 10:23:44 +0200
  6. Via: uk.ac.edinburgh.castle; Wed, 28 Apr 1993 09:22:56 +0100
  7. To: www-talk@nxoc01.cern.ch
  8. Subject: Extending HTML
  9. From: Chris Adie <cja@castle.edinburgh.ac.uk>
  10. Reply-To: C.J.Adie@edinburgh.ac.uk
  11. Date: Wed, 28 Apr 93 9:21:49 WET DST
  12. Message-Id: <9304280921.aa24764@castle.ed.ac.uk>
  13.  
  14. RARE has set up a short study on network access to multimedia
  15. information, which I am conducting.  I'm listening to the discussions on
  16. extending HTML and HTTP with great interest. 
  17.  
  18. Talking to some of the potential USERS of multimedia information servers
  19. (MMIS) and looking at their projects, I came up with a list of
  20. requirements.  I know that WWW can do much of this, but not all, and it
  21. seems that this might be a good time to mention some of these
  22. requirements.  There are sections on Hyperlinks, Presentation (this
  23. matches up with discussions on text flowing, inline images etc),
  24. Searching, QoS and Management.  I'd be interested in comments. 
  25.  
  26. HYPERLINKS
  27.  
  28. It is clear that many applications require their users to be able to
  29. navigate through the information base according to relationships
  30. determined by the information provider - in other words, hyperlinks. 
  31.  
  32. Some "hypermedia" systems are in fact simply hypertext, in that they
  33. require the source anchor of a hyperlink to be in a text node.  A true
  34. hypermedia system allows hyperlinks to have their source anchors in
  35. nodes of any media type.  This allows a user to click the mouse on a
  36. component of a diagram or on part of a video sequence to cause one or
  37. more related nodes to be retrieved and displayed. 
  38.  
  39. Some hypermedia systems allow target anchors of a hyperlinks to be
  40. finer-grained than a whole node - eg the target anchor could be a word
  41. or a paragraph within a text document.  It is not clear to me whether
  42. this is a critical requirement.
  43.  
  44. PRESENTATION
  45.  
  46. Related information of different media types must be capable of
  47. synchronised display.  The synchronisation may be in time and/or space. 
  48. For instance, an image may have an associated text caption which should
  49. be retrieved at the same time as the image and displayed adjacent to it,
  50. perhaps in a window which the user can scroll.  A sound clip may have
  51. some associated text (perhaps a translation) which must be displayed in
  52. sync with the sound, eg in an automatically-scrolled window. 
  53.  
  54. SEARCHING
  55.  
  56. Database-type applications require varying degrees of sophistication in
  57. retrieval techniques.  Typically, non-text nodes form the major data of
  58. interest.  Such nodes have associated descriptions, which may be plain
  59. text, or may be structured into fields.  Users need to be able to search
  60. the descriptions, obtain a list of "hits", and select nodes from that
  61. list to display.  Searching requirements vary from simple keyword
  62. searching to full-text indexing (with or without Boolean combinations of
  63. search words), to full SQL-style database retrieval languages.
  64.  
  65. The user must be able to retrieve and display all the information in a
  66. record in a single operation.  (This may involve several separate
  67. retrieval operations "under the hood", but the user should not be aware
  68. of this.)
  69.  
  70. QUALITY OF SERVICE
  71.  
  72. User toleration of delay in computer systems depends on user perception
  73. of the nature of the requested action.  If the user believes that no
  74. computation is required, tolerable delays are of the order of 0.2s.  If
  75. the user believes the action he or she has requested the computer to
  76. perform is "difficult" - for instance a computation of some form - then
  77. a tolerable delay is of the order of 2s.  Users tend to give up waiting
  78. for a response after about 20s.
  79.  
  80. Such user expectations are difficult to meet, particularly for
  81. voluminous multimedia data.  There are several ways of alleviating this
  82. problem, some of which are described below. 
  83.  
  84.  *    Give clues that fetching a particular item might be timeconsuming -
  85.     simply quoting the size may be sufficient. 
  86.  
  87.  *    Display a "progress" indicator while fetching data. 
  88.  
  89.  *    Allow the user to interact with other, previously fetched information
  90.     while waiting for data to be fetched. 
  91.  
  92.  *    Allow several fetches to be performed in parallel. 
  93.  
  94.  *    Pre-fetch information which the client software believes the user
  95.     will wish to see next. 
  96.  
  97.  *    Cache information locally. 
  98.  
  99.  *    Where multiple copies of the same information are held in different
  100.     network locations, fetch the "nearest" copy.  This is (sometimes)
  101.         known as "anycasting". 
  102.  
  103.  *    Offering multiple views of image or video data at different
  104.     resolutions and therefore sizes enable the user to select a balance
  105.     between speed of retrieval and data quality. 
  106.  
  107.  *      Make provision for using isochronous data streams (if available)
  108.         for audio and video.
  109.  
  110. MANAGEMENT
  111.  
  112. In order to support applications involving real-money information
  113. services (eg academic publishing) and learning/assessment applications,
  114. there must be a reliable and secure access control mechanism.  A simple
  115. password is unlikely to suffice - Kerberos authentication procedures are
  116. a possibility. 
  117.  
  118. Users must be able to determine the charge for an item before retrieving
  119. it (assuming that pay-per-item will be a common paradigm - alternatives
  120. such as pay-per-call, pay-per-duration are also possible).  Access
  121. records must be kept by the information server for charging purposes. 
  122.  
  123. Learning applications have similar requirements, except that the purpose
  124. here is not to charge for information retrieved, but to monitor and
  125. perhaps assess a student's progress. 
  126.  
  127. OTHER
  128.  
  129. Another requirement which has escaped from the above list is the ability to
  130. specify in a hypermedia document a mail address, in such a way that the
  131. user can click on it to invoke his/her mailer with the address ready
  132. in the To: field.
  133.  
  134. Chris Adie                                   Phone:  +44 31 650 3363
  135. Edinburgh University Computing Service       Fax:    +44 31 662 4809
  136. University Library, George Square            Email:  C.J.Adie@edinburgh.ac.uk
  137. Edinburgh EH8 9LJ, United Kingdom
  138.  
  139.